Can you explain why are we changing this? Is it because the hash map from hashbrown by default only generates a completely new seed once at startup? In which case we could probably just do:

use ahash::AHashSet as HashSet;

instead, which would still use ahash (which is going to be faster than the default hash in Rust's std), but it will use its RandomState which will always give a unique seed to each hash map/hash set.

Here's an example program to demonstrate:

use core::hash::BuildHasher;
use core::hash::Hasher;

fn main() {
    println!("ahash::AHashSet");
    for _ in 0..2 {
        let mut h = ahash::AHashSet::<i32>::new();
        let mut hs = h.hasher();
        let mut hh = hs.build_hasher();
        hh.write_u32(1234);
        println!("  {:?}", hh.finish());
    }

    println!("std::collections::HashSet");
    for _ in 0..2 {
        let mut h = std::collections::HashSet::<i32>::new();
        let mut hs = h.hasher();
        let mut hh = hs.build_hasher();
        hh.write_u32(1234);
        println!("  {:?}", hh.finish());
    }

    println!("hashbrown::HashSet");
    for _ in 0..2 {
        let mut h = hashbrown::HashSet::<i32>::new();
        let mut hs = h.hasher();
        let mut hh = hs.build_hasher();
        hh.write_u32(1234);
        println!("  {:?}", hh.finish());
    }
}

Result:

ahash::AHashSet
  9713553790381145631
  1617804629700195850
std::collections::HashSet
  12330284507346958173
  15536535817085373979
hashbrown::HashSet
  3076938710444694377
  3076938710444694377

Yeah, I also told @cheme the same. But in general, I don't see any big problem of just removing hashbrown.

Yes, it is totally right to use hashbrown. (when I write this I did check hashbrown code on a local fork that was reallly outdated and it was still using comptime_rand, but it is not the case anymore since 2020 :).

I only let the PR to avoid having hashbrown dependency here (one less dep in the Cargo.toml), but it really don't have to be merge, so just to lower deps number.

I only let the PR to avoid having hashbrown dependency here (one less dep in the Cargo.toml), but it really don't have to be merge, so just to lower deps number.

Well, ultimately even if you do remove the hashbrown dependency it won't actually get removed, because schnellru will always depend on hashbrown, so we'll still be using it transitively anyway.

Anyway, you can remove hashbrown if you want (as the HashSet in std is hashbrown anyway); I'd just like to keep the faster hasher from ahash as-is, since this part of the code is speed sensitive.

Of course, this should not change the actual generated code (only make sense so user/reader don't ask themselve why we have hashbrown and also for version mgmt even if if we want to strictly check speed at each version update it may make sense to keep hashbrown).

I'd just like to keep the faster hasher from ahash as-is, since this part of the code is speed sensitive.

Can you please do this @cheme?

I'd just like to keep the faster hasher from ahash as-is, since this part of the code is speed sensitive.

Can you please do this @cheme?

Sure (I kind of miss the info 🙈)

@koute please.